thoughts (as a fellow contributor):

sending the data

is there a reason it couldn't be sent as POST request params, like when you're previewing it?

also i just checked how dreamwidth does it, and it actually has both the comment preview and the edit form on the preview page. that's maybe an even better alternative to jumping between different pages?

shared template

that would make total sense to do, you could call it _comment_content.html.erb

The style rule for text-align: right

i don't see any any div.actions.right elements here so i'm not sure what its purpose is?

also i just checked how dreamwidth does it

i also just noticed that the dreamwidth comment preview page also has a copy of whatever post or comment you're replying to... not sure if livejournal's previews that sarken mentioned are the same

but i suppose you could also just use javascript by default to fetch the preview and insert it somewhere in or near the comment form, and only fall back to a separate page without it

@slavalamp Hi! Thanks for the feedback.

I'll definitely look into a preview that includes the comment one is replying to if one exists. I am also willing to workshop the actual design of the preview page.

One thing to note, though, is that the request (and, from what I understand, AO3 in general) asked for JavaScript-based features to be avoided. If it didn't, I would have approached all of this completely differently. So, with that in mind, we are certainly more limited on what can be done.

That being said, I think having the preview and the edit form on the same page makes sense. I was trying to imitate the work preview flow, but I think since comments are generally shorter, having them on the same page is more reasonable. I'll also start working on showing the parent comment alongside the preview comment; that's a great idea, and I think it should be possible to implement.

I also mentioned creating a comment template for this and other features, but I think I decided to do that in a different PR, so this doesn't become too bloated a change. I'll also probably revert my ts() to t() changes outside of what Rubocop suggested for the same reasons; the PR is already pretty big as it is, and I'd like to avoid scope creep so that this can go out sooner.